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Precede securise d'echange de donnees entre un navigateur et un site 
WEB. 

Domatne technique 

5 L'invention se rapporte a un proc6d6 d'echange securise de donn6es entre 

deux dispositifs de traiternent de donnees. La presente invention s'applique tout 
particulierement a un echange de donnees entre un dispositif incluant de 
preference une carte a puce dotee d'un navigateur (browser en anglais) et au 
moins une ressource informatique telle qu'un site WWW (World Wide Web) plus 

10 commun6ment appele site WEB (Web sites site en anglais), un serveur incluant 
des services, etc. 

Le dispositif couple a la carte k puce peut §tre d'un type quelconque. Ce 
systeme peut etre de type embarqu6 ou non. Rappelons qu'un systeme 
embarque est par exemple un telephone mobile, un assistant electronique, un 
15 ordinateur portable, etc. 

Le procede de l'invention s'applique. tout particulierement aux 
communications utiiisant un algorithme de chiffrement de type symetrique. 

L'exemple qui servira a illustration de ('invention sera celui d'une carte k 
puce couplee k un systeme embarqu6 communicant avec une plurality de 
20 ressources. 

Etat de la technique 

Une carte comprend gen^ralement un navigateur (browser en anglais), 
dgalement appele logiciel de navigation par Phomme du metier. Ce navigateur 
25 donne la possibility a un telephone mobile d'acceder a des services en ligne ou & 
des services locaux de type WAP. 

De maniere a assurer un ^change de donnees s6curis§ entre un navigateur 
stocke dans la carte a puce et un site WEB, on emploi des moyens 
cryptographiques tels que le cryptage ou la signature Electronique. 
30 II existe deux types de cryptographie : 

- la cryptographie conventionnelle utiiisant des cles sym^triques, 
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- la cryptographie a cle publique utilisant des cles asymetriques. 

L'utilisation de la cryptographie a cle publique requiert un espace memoire 
important. Sa mise en ceuvre presente d'enormes difficulty dans une carte a 
puce dans laquelle la taille memoire est limitee en nombre d'octets. C'est 

5 pourquoi la plupart des navigateurs utilisent la cryptographie a cle symetrique. 
Cependant, l'utilisation de la cryptographie a cle symetrique pose aussi des 
problemes dans une carte a puce. En effet, un navigateur ne peut pas stacker 
toutes les cles de tous les sites WEB avec lesquels il communique. Par 
consequent, lorsque I'utilisateur du navigateur desire echanger des informations 

10 avec un site WEB de maniere securisee, le site WEB doit initialement 
transmettre des cles au navigateur pour les utiliser ulterieurement lors 
d'operations d'encryption et/ou de signature. Le probleme aujourd'hui est que les 
sites WEB n'acceptent pas le partage de leurs cles avec d'autres sites WEB. En 
d'autres mots, si un site WEB "A" installe des cles dans un navigateur pour les 

15 utiliser ulterieurement, ce site WEB "A" refuse qu'un site WEB »B'« puisse les 

eff acer ou les utiliser. 

Cette situation cree un "trou de securite" pour les transactions securisees 
basees sur I'encryption symetrique, et, par voie de fait, un manque de confiance 
a la fois de la part des utilisateurs et de la part des sites WEB. 
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L'invention 

Un but de l'invention est d'obtenir une meilleure confiance en l'utilisation de 
la carte a puce pour realiser des transactions. 

25 L'invention concerne une carte a puce comprenant un navigateur pour 

communiquer avec un site WEB incluant des pages WEB, caracterise en ce que 
- le navigateur comprend une pluralite de zones privees, chaque zone privee 
pouvant etre allouee a un ensemble de ressources respectif et pouvant stocker 
des informations de securite propre a assurer une communication securisee 

30 entre une zone privee et un ensemble de ressources ; 
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- et en ce qu' un programme assure qu'un ensemble de ressources communique 
exclusivement avec la zone priv6e qui lui est allouee. 

Une zone priv<§e comprend des donn^es applicatives permettant d'6tablir 
5 une liaison securis6e avec un ensemble de ressources. Ces donn6es peuvent 
§tre des cles ^encryption symmetriques, des pages r6sidentes, etc. 

A noter qu'un ensemble peut contenir un ou plusieurs sites WEB. 

10 De cette fagon, dans la carte, chaque zone peut §tre allou6e k un ensemble 

de sites WEB particulier. Les donn6es applicatives formant chaque zone priv6e 
ne sont done accessibles que par Pensembie de sites WEB concern^ emp§chant 
ainsi un autre ensemble de sites WEB d'utiliser une zone qui ne lui a pas ete 
alloude. 

15 

Uinvention sera mieux comprise b. la lecture de la description qui suit, 
donn6e a titre d'exemple et faite en reference aux dessins annexes. 



Dans les dessins : 

20 . La figure 1 est une vue d'un systeme informatique sur lequel peut s'appliquer 
Finvention. 

La figure 2 est une vue schematique des differentes stapes illustrant un exemple 
d'6change de donndes entre un navigateur et une pluralite de sites WEB. 
La figure 3 est une vue des deux grandes etapes constituant une transaction 
25 s6curisee. 

Les figures 3 & 6 sont des vues sch^matiques des paramfetres d'entree et des 
parametres de sortie d'exemples de programmes mettant en ceuvre I'invention. 
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Descrjejjon defeaillee d'un aaamnte IHu ^ant ''t"v®"*'Q n 

Pour simplifier la description, les memes elements portent les memes 

r©f ©r©nc©s 

La figure 1 represente un systeme informatique SYS. Dans notre exemple 
5 illustre, ce systeme inclus plusieurs navigateurs (BW1-BW2) stockes dans une 
carte a puce (CARD1 -CARD2) respective. Dans notre exemple de realisation, 
Chaque carte a puce (CARD1-CARD2) est couplee a un telephone mobile 
respectif (MOB1-MOB2). A noter qu'un navigateur peut etre stocke 
indifferemment dans la carte ou dans le telephone mobile. 
10 Un navigateur peut communiquer par I'intermediaire d'un reseau RES avec 

une pluralite de sites WEB1 et WEB2. Generalement, un fournisseur d'acces AC 
s'intercale sur le reseau entre le navigateur (BW1-BW2) et un site WEB1-WEB2. 

Dans notre exemple, chaque utilisateur UT1-UT2 interagit avec le 
navigateur BW1-BW2 respectif par I'intermediaire d'une interface utilisateur 

15 respective GU1 1 etGUI2. 

Selon Invention, chaque navigateur BW1 et BW2 comprend des zones 
privees ZP1-ZP2 et ZP3-ZP5, respectivement. Chaque zone privee comprend 
des donnees applicatives. 

Pour des raisons de securite, ces differentes zones sont stockees dans la 
20 carte a puce. De cette fagon, les zones ne sont accessibles que par le 
proprietaire de la carte a puce. 

De preference, chaque zone comprend : 
- un parametre VASid identifiant la zone privee en question. De preference, cette 
vafour est une vaieur Tixee~pan3efalItT 



25 - une cle VMK; Cette cle sera appelee cle maftre dans la suite de la description ; 

- eventuellement, une page d'accueil propre a la zone privee ; 

- eventuellement, un ensemble de pages residentes associees a la page 
d'accueil ; 



De preference, la vaieur de la cle VMK est renseignee avant I'utilisation 
la zone privee. 
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Dans notre exemple illustre, en reference a la figure 2, le precede comprend 
deux etapes principles : 
- A) Tauthentification AUT, 
5 - et B) l'administration ADM. 

Dans notre exemple illustre, en reference aux figures 2 et 3, les etapes du 
precede sont enumerees ci-dessous. A noter que dans I'exemple illustrant les 
etapes du precede, on considere que l'utilisateur UT1 souhaite communiquer 
10 avec le site WEB1 . Pour des raisons de simplification de I'expose de I 'invention, 
la carte CARD1 et le telephone mobile MOB1 n'ont pas ete representees sur la 
figure 3. 

M L'authentification 
15 Etaoe 1 

Initialement, l'utilisateur UT1 souhaite obtenir un service du site WEB1 et 
communiquer en toute securite avec ce site. 

L'utilisateur contacte I'administrateur du site WEB1 et lui donne le nom du 
gestionnaire OP du navigateur BW1 ; La fonction de ce gestionnaire est 
20 notamment de fournir au site WEB1 certains parametres qui lui permettront de 
communiquer avec la zone privee qui lui a ete allouee et non une autre. 

L'utilisateur peut egalement donner le nom du fournisseur d'acces AC k 
I'administrateur du site WEB1. Dans ce cas, dans I'etape 2, le site WEB1 
contacte le gestionnaire OP par I'intermediaire du fournisseur d'acces AC (ce cas 
25 est represents par les lignes en pointille sur la figure 3). 

Etape 2 

Lors d'une deuxieme etape, le site WEB1 contacte le gestionnaire OP. 
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Etape 3 

Ensuite, lors d'une troisieme etape, le gestionnaire OP donne au site WEB1 
toutes les informations pour proceder a un echange de donnees securise avec 
une zone privee particuliere. Dans notre exemple de realisation, le gestionnaire 
5 fourni au site WEB1 : 

- I'identifiant VASid ; 

- la cl<§ VMK ; 

- et eventuellement d'autres informations telles que 

la taille d'une page d'accueil et des pages r6sidentes dans la carte ; 
10 - le nombre de pages residentes ; 

I'identifiant du navigateur BWid. 

Etape 4 

Dans notre exemple de realisation, I'administrateur du site WEB1 transmet, 
15 lors d'une quatrieme etape, a I'utilisateur 

- un identifiant USERID 

- un mot de passe PW 

De preference, la transmission est realisee par un moyen securis6 tel qu'un 
courrier postal. 

20 Dans notre exemple de realisation, le site WEB1 stocke aussi ces deux 

parametres dans une memoire, ou une base de donnees BDD auquel il est 
connecte, pour une utilisation ulte>ieure. 



Etane 5 _ — 

25 Lors d'une cinquieme 6tape, le site WEB1 transmet au navigateur BW1 une 

page incluant des champs a completer. Dans notre exemple, ces champs 

correspondent : 

- a I'identifiant USERID ; 

- et au mot de passe PW. 



30 
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Dans notre exemple, cette page inclus une reference propre h activer un 
programme VBA install^ dans la carte. 

Etaoe 6 

5 Lors d'une sixieme 6tape, le navigateur execute le programme VBA, Le 

programme VBA a une fonction d'authentification et a pour but notamment 

- de demander a I'utilisateur son identifiant USERID et son mot de passe PW 

- et de construire une requete incluant par exemple I'identifiant USERID et le mot 
de passe PW. 

10 

Les differentes phases d'execution de ce programme VBA sont 6num6r6es 
cl-dessous. 
Programme VBA : 

Dans notre exemple de realisation, et en reference a la figure 4, ce 
15 programme comprend des parametres d'entree PE1 et des parametres de sortie 
PS1. Les parametres d'entree sont : 

- la valeur de lMdentifiant VASid de la zone privee allouee au site WEB1 

- et des references a savoir : 

- Tidentifiant USERID de i'utilisateur 
20 - le mot de passe PW de I'utilisateur. 

Les parametres de sortie PS sont : 

- la valeur de Tidentifiant VASid 

- la valeur de I'identifiant USERID 

- la valeur de i'identifiant du navigateur BW 
25 - la valeur cryptee du mot de passe PW 

- des donnees de securite telles qu'un nombre aleatoire, une signature, etc. 

Ces parametres de sortie sont stock6s sous la forme d'une requite g6n§ree 
au cours de la phase 5 decrite ci-dessous. 

Dans notre exemple de realisation, Tex6cution de ce programme comprend 
30 plusieurs phases : 
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Phase 1 

Lors de la premiere phase, le programme VBA selectionne la zone privee 
correspondant a I'identifiant VASid. 

5 Phase 2 

Le programme stocke, lors d'une deuxieme phase, la valeur de I'identifiant 
USERID dans la zone privee. 

Phase3 

10 Lors d'une troisieme phase, le programme calcul une cle de session en 

utilisant la cle maTtre VMK connue a la fois du navigateur et du site WEB1, et 
d'autres parametres tels que Pidentifiant VASid, le nombre aleatoire, etc. Cette 
cle de session est calculee a partir d'un certain nombre d'informations: VMK, 
BWid, un nombre aleatoire, etc. Dans notre exemple de realisation, cette cle a un 

15 role tres temporaire. Elle ne sert qu'a crypter le mot de passe de I'utilisateur. 

Phase 4 

Lors d'une quatrieme phase, le programme chiffre le mot de passe en 
utilisant la cle de session. 
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Phase S 

Lors d'une cinquieme phase, le programme construct une requete. 



Etape 7 



25 Une septieme etape consiste pour la carte a transmettre la requdte au site 

WEB1. 

Etape 8 

Le site WEB1 verifie la requete recue, en I'occurrence Tidentifiant USERID 
30 et le mot de passe PW. Pour ce faire, le site WEB1 genere d'abord la cle de 
session qui doit §tre identique a celle g§neree par le navigateur durant la phase 



9 



3 de I'etape 6. Le site WEB1 peut alors decrypter le mot de passe PW en utilisant 
la cle de session VMK ;Pour realiser cette verification, le site WEB1 interroge la 
base de donnees BDD, et compare Pidentifiant et le mot de passe recu du 
navigateur avec ceux prealablement stockes dans la base BDD. 
5 Dans notre exemple, le site WEB1 calcule egalement la signature de la 

requite recue a partir de la cle de session. II compare ensuite le resultat avec la 
signature indue dans le message. 

Etaoe 9 

10 Si le resultat de la verification est positif, I'authentification est terminee. La 

zone privee et la carte peuvent communiquer. Dans notre exemple, Isi le resultat 
est positif, le site WEB1 transmet a la carte une page comprenant : 

- un programme VA 

- un programme IVK 
15 - un programme IRP 

Cette page, plus precisement les programmes associes, ont pour fonction 
d'administrer la zone privee allouee au site WEB1 . 

B\ L'administration 

20 L'authentification etant realisee, l'administration de la carte est realisee par 

I'intermediaire de programmes (plug-in en anglais) qui permettent au navigateur 

d'utiliser la zone privee allouee a un site WEB1 . 

Par consequent, lors de la neuvieme etape, l'administration des zones 

privees debute. Le navigateur execute cette page, a savoir I'ensemble des 
25 programmes. Les differentes phases d'execution de I'ensemble des programmes 

VA, IVK, IRP sont enumerees dans la suite de la description. 

Le programme VA 

Premierement, il execute le programme VA. La figure 5 illustre un exemple 
30 schematique des entries PE2 de ce programme. Le programme VA a une 
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fonction d'authentification. Ce programme autorise le site WEB1 d'dtre 
authentifie par le navigateur BW1 . 

Dans notre exemple, ce programme VA comprend des parametres d'entr<§e 
PE2 et de sortie. Le parametre de sortie est un signal informant si une 
5 transaction peut etre lancee.. Les parametres d'entree PE2 sont dans notre 
exemple : 

. ia valeur de I'identifiant VASid qui permet au navigateur de s6Iectionner la zone 
privee adequate ; 

- la valeur de I'identifiant USERID ; 
10 - des donnees de security. 

Execution du programme VA 

Dans notre exemple illustre, I'execution de ce programme comprend 
plusieurs phases. Dans notre exemple, ces phases sont les suivantes : 

15 

Phase 1 

Le programme selectionne la zone privee correspondant a I'identifiant 
VASid. 

20 Phase 2 

Le programme venfie la valeur de I'identifiant USERID avec celle stockee 
dans la zone privee. 



Phase 3 . 

25 Le programme calcul une cle de session VSK en utilisant la cle mattre VMK 

ainsi que d'autres donnees, par exemple un nombre aleatoire, une signature, un 
compteur de synchronisation, etc. 
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Phase 4 

Le programme VA verifie les donnees de security a savoir le nombre 
aleatoire, la signature, le compteur de synchronisation, etc. Cette verification 
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permet de s'assurer que les donnees de securite associees a la zone priv£e en 
question correspondent aux donnees de security de la zone privee allouee au 
siteWEBL 

5 Si le resultat de la verification est positif , le navigateur lance une transaction 

securisee avec le site WEB1 et la zone privee allouee- Dans la negative, aucune 
transaction n'est lancee et le navigateur affiche par exemple une page d'accueil 
publique. 

10 De preference, quand une transaction est Ianc6e, la cle de session est 

stock6e parce qu'elle peut etre utilisee pendant toute une session. Cependant, 
dans notre exemple de realisation, lorsque la transaction est termin6e ou que le 
resultat de la verification faite a la phase 4 est nggatif, la cle de session est 
effac^e. 

15 

Une transaction s6curis£e reste ouverte pendant toute la dur£e de 
I'execution de la page courante. De preference, cette transaction est ferm6e 
quand le navigateur regoit une nouvelle page. Par consequent, si un site WEB 
desire utiliser une transaction securisee sur plusieurs pages, il devra inserer 
20 I'appel du programme VA au d6but de chacune des pages envoydes au 
navigateur. 

Si une transaction est Ianc6e, le navigateur peut executer les deux autres 
programmes IVK et IRP : 

25 

Le programme IVK 

Ce programme a pour fonction le chargement de cles chiffrees dans la zone 
privee. Dans notre exemple de realisation, ce programme comprend des 
paramdtres d'entr6e PE3 et un parametre de sortie PS3. Dans notre exemple, 
30 les paramfctres d'entr£e sont des cl£s chiffrees qui peuvent §tre la cle maitre 
VMK ou les cles de d'encryption/signature regues du site WEB1. Ces cles 
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d'encryption/signature sont les cles symetriques cities dans le paragraphe "Etat 
de la technique". Elles font partie des "donnees applicatives" citees dans le 
paragraphe Tinvention". Ce sont elles qui seront utlisees ulteneurement pour 
encrypter ou signer des informations echangees entre le navigateur et le site 
5 WEB1. 

Le parametre de sortie est un signal informant que le chargement a ete ou 
non realise avec succes. 

10 Lorsque le navigateur execute ce programme, il verifie qu'une transaction 

est lancee. Si c'est le cas, le programme selectionne la zone privee en question. 
Une fois la selection effectuee, le programme decrypte les cles symelriques 
recues du site WEB1 en utilisant la cle de session VSK et les stocke dans la 
zone privee. Le nombre de cles est quelconque. 

15 

Le programme IRP 

Ce programme a pour fonction de charger sort une page d'accueil chiffree 

dans la zone privee en question, sort une ou plusieurs pages residentes 

chiffrees. Ces pages font partie des "donnees applicatives" citees dans le 
20 paragraphe 'Tinvention ". 

Dans notre exemple de realisation, ce programme IRP comprend un 

parametre d'entree CRP qui est une page residents chiffree issue du site WEB1. 

Cette page peut etre sort une page d'accueil ou une page residente. Le 

P^ramptrp ri R sortie ^t)'S7F^IL~est un mes-sWe-ih-diqQant-si-oor-ou-norr 
25 I'installation des pages a ete realisee avec succes ou si au contraire Nnstallation 

a echoue. 

Lorsque le navigateur execute le programme IPR, il veYifie qu'une 
transaction securisee est Ianc6e. Si c'est le cas, le programme selectionne la 
zone privee en question. Ensuite, le programme decrypte la page rogue en 
30 utilisant la cl§ de session VSK et stocke la page dans la zone privee en question. 
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Etane 10 

Lors de cette dixieme etape, les differents resultats obtenus par les 
differents programmes lances au cours de I'etape 9 sont transmis au site WEB1. 

5 Etape 11 

Lors d'une onzieme etape, le site WEB1 verifie les resultats obtenus par les 
differents programmes. Si les resultats obtenus conviennent, le site WEB1 peut 
utiliser sa zone privee. Dans notre exemple de realisation, le site WEB1 peut 
realiser des transactions utilisant les cles symetriques. 

10 

Etape 12 

Lors d'une douzieme 6tape, le site WEB1 transmet alors au navigateur une 
page qui comprend le programme VA, des operations de signature ou de 
chiffrage, un lien vers une page residente, etc. 

15 

Etape 13 

Dans notre exemple, lorsque le navigateur a recu cette page, la transaction 
est fermee. Le navigateur execute alors le programme VA. Si le resultat de la 
verification est positif, le navigateur lance une nouvelle transaction securisee 
20 avec le site WEB1 et la zone privee aiiouee. C'est la phase d'utilisatioh de la 
zone privee. Le site WEB1 peut ainsi realiser des operations de chiffrage et de 
signature en utilisant les cles symetriques associees k la zone privee en 
question. Le navigateur peut aussi acceder aux pages residentes privees 
prec6demment chargees par le programme IRP. 

25 

Cet exemple de realisation montre bien qu'une ressource peut etre 
indifferemment un site WEB, ou tout autre dispositrf apte a communiquer avec 
une carte a puce. 

30 
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On a vu notamment que i'autorisation d'utilisation d'une zone privee est 
realisee par un programme comprend au moins un parametre d'entree 
correspondant a une cle d'acces a une zone. Dans notre exemple cette cle 
d'acces est constitute par le USERID et le mot de passe PW. On a vu aussi que 
5 la valeur de cette cle est foumle par I'ensemble des ressources concerns, c'est- 
a-dire I'ensemble des sites WEB dans notre exemple. Ce programme est apte 
apres execution et en fonction de cette cle a autoriser I'acces a une zone privee 
et interdire I'acces aux autres zones privees. 

10 Dans notre exemple, on vu comment s'effectuait rauthentification entre une 

zone privee et le site WEB correspondant. L'ensemble de ressources transmet 
au navigateur une requite apte a demander a I'utilisateur d'entrer la cle d'acces 
recue. Ensuite, si la cle d'acces est correcte, le dispositif comprend des 
instructions de code aptes a assurer la gestion de rauthentification entre un 

15 ensemble de sites WEB et la zone privee allouee correspondante. 

On a vu aussi que le dispositif interprete des instructions de code aptes a 
assurer, apres I'etape d'authentification et par l'intermediaire des informations de 
securite, la gestion de ('administration des zones privees, ainsi que I'utilisation 
20 des donnees applicatives de ces zones privees pendant une communication 
entre le navigateur et le site WEB. 

Dans notre exemple de realisation, on a vu que les donnees de securite 

— comprennent au moins une ole maftre ffiKTlK). 

25 

D'une maniere generate, le precede comprend les etapes suivantes : 

- une etape de creation d'une pluralite de zones privees, chaque zone privee 
pouvant etre allouee a un ensemble de ressources respectif et pouvant stocker 
des informations de securite propre a assurer une communication securisee 

30 entre une zone privee et un ensemble de ressources ; 

- une etape d'allocation d'une zone privee a un ensemble de ressources, 
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- une (§tape de communication entre ladite zone privee allouee et I'ensemble des 
ressources concerne, un programme interdisant tout acces a une autre zone 
privee pendant cette communication. 

5 Avantageusement, on a vu que relocation d'une zone privee est geree par 

une entite centralisee OP. Cette entite alloue une zone privee de ia carte a 
I'ensemble des ressources WEB en iui fournissant des informations comprenant 
au moins: 

- la reference (VASId) de la zone privee, 

10 - et la valeur d'une cle maitre (VMK) stockee au prealable dans la zone privee 
correspondante. 

Dans notre exemple, on a vu que I'ensemble de ressources (WEB) transmet 
par un moyen de transmission securise au moins une cle d'acces associee a une 
15 zone privee, ladite cle etant utilise pour I'execution d'un programme apte, apres 
execution, k autoriser I'acces a une zone privee et interdire I'acces aux autres 
zones privees. 

Dans notre exemple, on a vu aussi que, afin d'ouvrir une transaction 
20 securisee, I'ensemble de ressources (WEB1) transmet un programme apte a 
verifier si les informations de securite inscrites dans la zone privee (ZP1) 
correspondent aux informations de securite stockees dans une memoire 
rattachee a I'ensemble de ressources (WEB1). 

25 On a vu dans notre exemple de realisation que la mise en oeuvre de ce 

procede necessite Installation d'un programme dans le dispositif. Ce 
programme d'ordinateur comprend au moins un parametre d'entree 
correspondant a une cle d'acces a une zone, la valeur de cette cle etant fournie 
par I'ensemble des ressources concerns, ledit programme etant apte apres 

30 execution en fonction de cette cle a autoriser I'acces a une zone privee et 
interdire I'acces aux autres zones privees. 
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Avantacses 

Grace a ce mecanisme de "cloisement" des informations accessibles par un 
5 navigateur, les cles d'encryption et les pages locales associes a une zone privee 
n'est accessible que par le site WEB concerne et non par d'autres sites WEB. 

Par consequent, ce mecanisme de cloisonnement permet I'acces 
uniquement au site WEB qui les a installees. 

La presente solution repond aussi a un second besoin du marche 
10 concernant Installation de pages locales (dites "residentes") accessibles par le 
navigateur. Les sites WEB peuvent installer des pages locales de facon 
securisee, et en permettre I'acces a I'utilisateur qu'apres authentication de celui- 
ci. Ces pages locales 6tant "la propriete" d'un site WEB particulier, elles ne 
peuvent plus etre effacees par ^installation de pages provenant d'un autre site 
15 WEB. 
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Revindications 

1. Dispositif de traitement de donnees (MOB1) apte a communiquer avec une 
pluralite de ressources (WEB1,WEB2)par I'intermediaire d'un navigateur (BW1), 
5 caracterise en ce que: 

- le navigateur (BW1) comprend une pluralite de zones privees (ZP1-ZP2), 
chaque zone privee pouvant etre allouee a un ensemble de ressources (WEB1) 
respectif et pouvant stacker des informations de securite propre a assurer une 
communication securisee entre une zone privee (ZP1) et I'ensemble de 

10 ressources (WEB1) ; 

- et en ce qu'il comprend un programme apte a assurer qu'un ensemble de 
ressources (WEBI)communique exclusivement avec la zone privee (ZP1) qui lui 
est allouee. 

15 2. Dispositif selon la revendication 1, caracterise en ce que ledit programme 
comprend au moins un parametre d'entree (USERID.PW) correspondant a une 
cle d'acces a une zone, la valeur de cette cle (faeces etant fournie de facon 
securisee par I'ensemble des ressources concerne (WEB1), ledit programme 
etant apte apres execution et en fonction de cette cle a autoriser I'acces a une 

20 zone privee (ZP1), et interdire I'acces aux autres zones privees (ZP2) du 
navigateur (BW1). 

3. Dispositif selon la revendication 1 ou 2, caracterise en ce que pour 
I'authentification, I'ensemble de ressources (WEB1) transmet au navigateur une 
25 requete apte a demander a I'utilisateur d'entrer la cle d'acces (USERID.PW) 
repue, et en ce que si la cle d'acces est correcte, le dispositif comprend des 
instructions de code aptes a assurer la gestion de rauthentification entre un 
ensemble de ressources (WEB1) et la zone privee allouee (ZP1) 
correspondante. 

30 
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4. Dispositif selon la revendication 1 ou 3, caracteris<§e en ce qu'il interprete des 
instructions de code aptes a assurer, apres I'etape d'authentification et par 
I'intermediaire des informations de securite, la gestion de I'administration des 
zones privees, ainsi que I'utilisation des donnees applicatives de ces zones 

5 privees pendant une communication entre le navigateur et le site WEB. 

5. Dispositif selon la revendication 1, caracterise en ce que les informations de 
securite comprennent au moins une cl6 maftre (VMK). 

10 6. Dispositif de traitement de donnees (MOB1) couple a une carte a puce 
(CARD1) apte a communiquer avec une plurality de sites (WEB1) par 
I'intermediaire d'un navigateur (BW1), caracterise en ce que: 

- e navigateur comprend une pluralite de zones privees (ZP1-ZP2), chaque zone 
privee pouvant §tre allouee a un ensemble de sites respectif et pouvant stocker 

15 des informations de securite propre a assurer une communication securisee 
avec un ensemble de sites; 

- et en ce que, le navigateur (BW1) interprete des instructions de code aptes a 
assurer qu'un ensemble de sites (WEB1) communique exclusivement avec la 
zone privee (ZP1) qui lui est allouee. 

20 

7. Procede de communication entre un dispositif de traitement de donnees 
(MOB1) comprenant un navigateur (BW1) et un ensemble de ressources 
(WEB1), caracterise en ce qu'il comprend les etapes suivantes : 
. n n ° *tapg H** ™*«tinn rt'una plurality rte yonesprivees (ZPNZP2)Tchaque zone 
25 privee pouvant etre allouee a un ensemble de ressources respectif et pouvant 
stoclcer des informations de securite propre a assurer une communication 
securisee entre une zone privee et un ensemble de ressources ; 

- une &ape d'allocation d'une zone privee (ZP1) a un ensemble de ressources 
(WEB1), 
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- une etape de communication entre ladite zone privee allouee (ZP1) et 
I 5 ensemble des ressources (WEB1) concerne, un programme interdisant tout 
acces a une autre zone privee pendant cette communication. 

5 8. Precede selon la revendication 7, caracterise en ce que I'allocation d'une zone 
privee (ZP1) est geree par une entite centralisee (OP), et en ce que cette entite 
alloue une zone privee (ZP1) de la carte (CARD1) a I'ensemble de ressources 
(WEB1) en lui fournissant des informations comprenant au moins: 

- la reference (VASId) de la zone privee ZP1, 

10 - et la valeur d'une cle maTtre (VMK) stockee au prealable dans la zone privee 
(ZP1) correspondante. 

9. Proceed selon la revendication 7, caracterise en ce que I'ensemble de 
ressources (WEB1) transmet par un moyen de transmission securise au moins 

15 une cle d'acces (USERID, PW) associee a. une zone privee (ZP1), ladite cle 
etant utilisee pour I'execution d'un programme apte, apres execution, a autoriser 
I'acces a la zone privee (ZP1) et interdire I'acces aux autres zones privees (ZP2). 

10. Procede selon la revendication 7, caracterise en ce que, afin d'ouvrir une 
20 transaction securisee, I'ensemble de ressources (WEB1) transmet un 

programme apte a verifier si les informations de securite inscrites dans la zone 
privee (ZP1) correspondent aux informations de securite stockees dans une 
memoire rattach^e a I'ensemble de ressources (WEB1). 

25 11. Programme d'ordinateur pour un dispositif de traitement de donnees apte a 
communiquer avec une pluralite de ressources par I'intermediaire d'un 
navigateur, caracterise en ce que le navigateur comprend une pluralite de zones 
privees, chaque zone privee pouvant etre allouee a un ensemble de ressources 
respectif et pouvant stacker des informations de securite propre a assurer une 

30 communication securisee entre une zone privee et un ensemble de ressources ; 
et en ce que le programme comprend au moins un parametre d'enttee 
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correspondant a une cle d'acces a une zone, la valeur de cette cle etant fournie 
par Tensemble des ressources concerne, ledit programme etant apte apres 
execution en fonction de cette cl(§ a autoriser I'acces a une zone privee et 
interdire I'acces aux autres zones privees. 
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